home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Tools & Utilities
/
Collection of Tools and Utilities.iso
/
archiver
/
crush1.zip
/
README
< prev
next >
Wrap
Text File
|
1994-06-18
|
13KB
|
250 lines
__________________________________________________________________________
CRUSH v1.0 Readme File
__________________________________________________________________________
CRUSH is a new shareware product from the same author as the awarding
winning DOS file manager PocketD Plus ("BEST UTILITY 1992" PsL and joint
runner-up WHAT PC's "BEST UTILITY 1994" with Stacker v4.0 & Dr Solomon's
Virus Toolkit). PocketD Plus has been upgraded to v4.1 to support CRUSH.
>>>>>>>> WHAT IS CRUSH ?
CRUSH is a compression tool that can work with your existing archiver
to dramatically reduce the size of archives created. In many
instances CRUSH achieves an average 2:1 advantage over PKZIP and 8:1
over uncompressed files. However CRUSH is neither slow nor
inconvenient to use. The command-line syntax is essentially similar
to PKZIP, but with many powerful extensions.
CRUSH will work with any of PKZIP, ARJ, LHA, ZOO and HA. The
archivers PKZIP and ARJ are Shareware and require registration
payments. LHA, ZOO and HA are Copyrighted Freeware.
>>>>>>>> HOW DOES IT WORK ?
The principal behind CRUSH is not new, but is not exploited by common
archivers. It takes advantage of the fact that big files will
generally compress better than small files, a property used by Unix
users who follow the maxim "always tar before compress" (joining
files together before compressing). CRUSH will automatically do this
for you, generating a single file with an extension "CRU" that it
compresses using your chosen archiver (default PKZIP). Extraction of
files is then very easy: UNCRUSH works in the same way as PKUNZIP.
CRUSH gets the most from this compression trick by taking it one step
further and intelligently ordering the files before joining them. It
does this by recognising file types, reading them where needed (to
recognise 7 different compressed header types), and orders them
accordingly. This yields a very good default fast compression.
Given more time CRUSH can do better by optionally performing a series
of trials to squeeze out extra compression. The algorithm for this
uses an intelligent re-ordering mechanism which analyses the results
of each intermediate test in order to determine which ordering to try
next. This was developed over a period of 2 years where it was
successfully used to reduce the file size of PocketD Plus to the
absolute minimum. This technique allows CRUSH to find near optimum
compression in a few minutes that might take hundreds of years using
more brute-force methods!
>>>>>>>> HOW GOOD IS IT?
Using CRUSH would not be worthwhile if it yielded a narrow advantage
over existing archivers, but in many situations it is capable of
delivering dramatically better compression. The results below are
genuine random tests performed on files taken from a 250-user PC
server and from a publically available CD-ROM.
All archivers were run with maximum compression, except CRUSH which
was set to minimum. The figures for Stacker and DoubleSpace are
commercially quoted performance figures for comparison, not test
results. All the figures quote the compression ratio in terms of disk
space used rather than actual file sizes (8k cluster assumed) to
allow comparison with Stacker 4.0. This does not significantly affect
the comparison between the other archivers (Figures for ZOO are not
quoted as it uses the same compression algorithm as LHA).
>>>>>>>> (1) CRUSH at its BEST -- Working with small data files
CRUSH works best with collections of similar small files. In a block test
of 128 directories (each compressed to its own archive) containing 2349
wordprocessing files (total 33 Megabytes), CRUSH with minimum optimisation
generated the following average compression ratio, calculated by:
Ratio = (disk space used by uncompressed files)/(space after compression)
Ratio
CRUSH+HA ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 7.95
CRUSH+PKZIP ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 7.82
CRUSH+ARJ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 6.16
CRUSH+LHA ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 5.46
HA 0.98 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 4.32
PKZIP 2.04g ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 4.11
ARJ 2.3 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 4.18
LHA 2.11 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 4.12
Stacker 4.0 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 2.50
DoubleSpace ▒▒▒▒▒▒▒▒▒▒▒▒▒ 1.90
Orig Files ▒▒▒▒▒▒▒ 1.00
CRUSH clearly yields a substantial improvement in all cases. Its worst
result is with LHA, but this is still much better than any non-CRUSH
compression.
>>>>>>>> HOW FAST IS CRUSH ?
These results might be of limited value if the cost in time for
compression was great. The chart below shows the compression times for 6
wordprocessing files, totalling 150k on a 486SX25 with a ramdrive:
Seconds
CRUSH+HA ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 11.04
CRUSH+ZIP ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 3.51
CRUSH+ARJ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 3.30
CRUSH+LHA ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 3.68
CRUSH+ZOO ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 8.57
HA 0.98 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 10.98
PKZIP 2.04▒▒▒▒▒▒▒▒▒▒▒▒ 2.26
ARJ 2.3 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 3.02
LHA 2.11 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 3.30
ZOO 2.1 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 7.85
From these compression and speed results it can be seem that CRUSH with HA
0.98 offers the best overall compression, but that CRUSH with PKZIP or ARJ
does nearly as well, but are both over 3 times faster.
>>>>>>>> (2) CRUSH at its WORST -- Working with large or dissimilar files
CRUSH has the most difficulty when given large or dissimilar files. A good
example of this might be a Shareware release file which contains a mixture
of documents, executable and other files. A test with minimum optimisation
on 40 random archive files from the ASP-CD ROM (17 Megabytes) yielded the
following results:
Ratio
CRUSH+HA ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 2.84
CRUSH+ZIP ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 2.80
HA 0.98 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 2.76
PKZIP 2.04g ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 2.70
ARJ 2.3 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 2.70
LHA 2.11 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 2.66
Stacker 4.0 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ (2.50)
Doublespace ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ (1.90)
Orig Files ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 1.00
Here, improved performance is somewhat less than the previous example,
corresponding to a 3.7% improvement with PKZIP. Many of the compressions
yielded a 0% improvement because although the newly compressed file may
have been smaller, it still occupied the same number of disk allocation
units (clusters). The average improvement in actual file size (important
for file downloads) was 5.6% for PKZIP, with a low of 1% and high of 28%.
The figures for Stacker and DoubleSpace are bracketed as